Management of CDMA credentials on a smart card

ABSTRACT

A method is performed by a user device and a smart card inserted into the user device. The method includes storing, in the smart card, information to permit the user device to communicate with a particular network; identifying a first smart card identifier associated with the smart card; identifying a second smart card identifier associated with a previous smart card inserted into the user device; comparing the first smart card identifier and the second smart card identifier to generate a first comparison result; pushing, by the smart card and to the user device, the information when the first comparison result indicates that the first smart card identifier matches the second smart card identifier; and obtaining, by the user device, access to the particular network using the information received from the smart card.

RELATED APPLICATION

This application is a divisional of co-pending U.S. patent applicationSer. No. 12/631,314, filed on Dec. 4, 2009, entitled “MANAGEMENT OF CDMACREDENTIALS ON A SMART CARD,” the disclosure of which is herebyincorporated by reference herein.

BACKGROUND

Mobile terminals may utilize Universal Integrated Circuit Cards (UICCs)to access various types of networks. A UICC is a smart card used inmobile terminals in global system for mobile communications (GSM) anduniversal mobile telecommunications system (UMTS) networks. The UICCensures the integrity and security of personal data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B are diagrams illustrating an exemplary implementation inwhich management of CDMA credentials on a smart card may be implemented;

FIG. 2 is a diagram illustrating an exemplary user device depicted inFIGS. 1A and 1B;

FIG. 3A is a diagram illustrating exemplary components of a user device;

FIG. 3B is a diagram illustrating an exemplary functional component ofthe user device;

FIG. 4A is a diagram illustrating exemplary components of a smart card;

FIG. 4B is a diagram illustrating exemplary functional components of thesmart card;

FIG. 5 is a flowchart of an exemplary process for provisioning networkdevices in a network;

FIG. 6 is a diagram illustrating an exemplary messaging scheme forprovisioning network devices prior to activation of a smart card;

FIG. 7 is a flowchart of an exemplary process for activating a smartcard;

FIG. 8 is a diagram illustrating an exemplary messaging schemeassociated with an activation procedure for a smart card when Long TermEvolution (LTE) coverage is provided in the network;

FIG. 9 is a diagram illustrating an exemplary messaging schemeassociated with an activation procedure for a smart card when evolvedHigh Rate Packet Data (eHRPD) coverage is provided in the network;

FIG. 10 is a diagram illustrating an exemplary messaging schemeassociated with an activation procedure for a smart card when 1X RadioTransmission Technology (RTT) (1XRTT) and HRPD coverage is provided inthe network;

FIG. 11 is a flowchart of an exemplary process that may occur when asmart card is moved from one user device to another user device;

FIG. 12 is a diagram illustrating an exemplary messaging scheme forobtaining configuration/programming information to configure/program auser device; and

FIG. 13 is a diagram illustrating an exemplary messaging scheme forupdating one or more network devices with information regarding a userdevice.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements. Also, the following detailed description does notlimit the invention.

As will be described herein, systems and/or methods may permit codedivision multiple access (CDMA) credentials to reside on a smart card,such as a UICC, so that a user may change user devices and the CDMAcredentials may follow. As used herein, the term “CDMA credentials”refers to information that a user device may use to connect to, or toaccess services and/or resources on, a CDMA network. Storing CDMAcredentials on a smart card is in contrast to existing approaches inwhich CDMA credentials may reside on the user device so that when theuser changes user devices, the CDMA credentials do not follow. Rather,under existing approaches, when the CDMA credentials reside on the userdevice, and the user changes to another user device, user interventionis required to re-provision the other user device. For example, the usermay need to interact, via the other user device, with a network that theuser wishes to utilize, so that the network may push the CDMAcredentials to the other user device. In contrast, according to thesystems and/or methods described herein, user intervention may not berequired when the user changes to another user device.

FIGS. 1A and 1B are diagrams illustrating an exemplary implementation inwhich management of CDMA credentials on a smart card may be implemented.FIGS. 1A and 1B illustrate an exemplary environment 100. In practice,environment 100 may include more, fewer, different, and/or differentlyarranged devices and/or networks than those illustrated in FIGS. 1A and1B. Additionally, or alternatively, in other implementations, one ormore functions described as being performed by a particular device ornetwork may be performed by a different device or a different network.Environment 100 may include wired and/or wireless connections betweenthe networks and the devices illustrated. The connections between thedevices and networks in environment 100 are exemplary, and in otherimplementations, the connections may be different.

As illustrated in FIG. 1A, a user 105 may operate a user device 110-1(referred to generically as “user device 110”), which may include asmart card 115, and communicate via network 125. The term “user device,”as used herein, is intended to be broadly interpreted to include adevice that may utilize a smart card (e.g., smart card 115). User device110 may correspond to a mobile device or a stationary device. By way ofexample, but not limited thereto, user device 110 may correspond to awireless telephone (e.g., a smart phone or a cellular phone), a personaldigital assistant (PDA), a pervasive computing device, a computer (e.g.,a laptop computer, a palmtop computer), an Internet Protocol (IP) phone,a music playing device, a web browsing device, a personal navigationdevice (e.g., a Global Positioning System (GPS) navigation device), amultimedia playing device, a gaming device, a vehicle-based device, atelevision set-top-box, or the like.

Smart card 115 may correspond to a Subscriber Identity Module (SIM)card, a UICC, or another type of smart card. Smart card 115 may includean integrated circuit and facilitate the connection of user device 110to network 125.

Network 125 may correspond to a network that provides one or moreservices. Network 125 may include, for example, a 2^(nd) Generation (2G)network (e.g., a Global System for Mobile communications (GSM) network),a 3^(rd) Generation (3G) network (e.g., a CDMA network), a 4^(th)Generation (4G) network (e.g., a Long Term Evolution (LTE) network), anevolved High Rate Packet Data (eHRPD) network, an HRPD network, anInternet Protocol (IP) Multimedia Subsystem (IMS) network, or the like.

In an exemplary scenario, user device 110-1 may establish a connection120 with network 125. Smart card 115 may initiate an activation request130 with network 125. In one implementation, activation request 130 mayinclude an identifier for user device 110-1 and an identifier for user105. For example, the identifier for user device 110-1 may include aunique identifier associated with user device 110-1 (e.g., anInternational Mobile Equipment Identity (IMEI)), and the identifier foruser 105 may include a unique identifier associated with user 105 (e.g.,an International Mobile Subscriber Identity (IMSI)). In otherimplementations, the identifier for user device 110 may correspond to adifferent type of user device identifier (e.g., a Mobile EquipmentIdentity (MEID), an Electronic Serial Number (ESN), or the like).Similarly, in other implementations, the identifier for user 105 maycorrespond to a different type of user identifier. In oneimplementation, user 105 and user device 110 identifiers may beincorporated with a fully qualified domain name (FQDN) (e.g.,IMEI@vz4g.com or IMSI@vz3G.com).

In this scenario, it may be assumed that network 125 recognizes, forexample, the identifier for user device 110-1, and responds with anactivation response 135. In one implementation, activation response 135may include a Mobile Station International Subscriber Directory Number(MSISDN), a Mobile Directory Number (MDN), a Mobile IdentificationNumber (MIN), a CDMA A12 Network Access Identifier (NAI), a PreferredRoaming List (PRL), a Public Land Mobile Network (PLMN) identifier,and/or a CDMA Network Access NAI. The MSISDN may correspond to a uniqueidentifier for a subscription in a GSM or UMTS network. The MDN maycorrespond to a directory number used to contact a user device. The MINmay correspond to an identifier that uniquely identifies a user device.The CDMA A12 NAI may correspond to a device access identifier (ID) topermit a user device to be authenticated. The PRL may correspond toinformation used during a system selection and acquisition process, suchas information identifying the bands, sub-bands, and service provideridentifiers to be scanned and in what order. The PLMN identifier mayidentify the network that user device 110-1 may utilize when roaming.The CDMA Network Access NAI may correspond to a subscriber NAI that maybe used during an authentication process.

Generally, smart card 115 may push 140 CDMA credentials to user device110-1. In one implementation, the CDMA credentials may include the MDN,the MIN, and the PRL. In another implementation, the CDMA credentialsmay include less information, additional information, or differentinformation. For example, the CDMA credentials might include the CDMAA12 NAI and/or the CDMA Network Access NAI. When smart card 115 isremoved from user device 110-1, the CDMA credentials may be removed fromuser device 110-1. In such an instance, user device 110-1 may not beable to operate with network 125 and/or a portion of network 125 (e.g.,a CDMA portion of network 125, etc.).

Referring to FIG. 1B, assume that user 105 uses smart card 115 with userdevice 110-2, where user device 110-2 is a different user device thanuser device 110-1. In one implementation, smart card 115 may read 145 auser device 110-2 identifier (e.g., an IMEI) of user device 110-2, anduser device 110-2 may read 150 a smart card identifier (e.g., anIntegrated Circuit Card ID (ICC-ID) or some other unique identifier ofsmart card 115). Smart card 115 may compare the user device 110-2identifier with a stored user device identifier. Similarly, user device110-2 may compare the smart card identifier with its stored smart cardidentifier. In the event that the smart card identifier and the userdevice identifier match with what is stored on smart card 115 and userdevice 110-2, smart card 115 may push 140 CDMA credentials to userdevice 110-2. User 105 may utilize user device 110-2 with network 125without a need for user intervention or any configuring/programming ofuser device 110-2. In the event that the smart card identifier and/orthe user device identifier do not match with what is stored on smartcard 115 and/or user device 110-2, smart card 115 may push 140 CDMAcredentials to user device 110-2. Additionally, network 125 may need tobe provisioned for user device 110-2, as will be described in detailbelow. However, user intervention still may not be needed.

As a result of the foregoing, CDMA credentials may reside on a smartcard so that a user may change user devices and the CDMA credentials mayfollow without user intervention. Since implementations have beenbroadly described, variations to the above implementations will bediscussed further below.

FIG. 2 is a diagram of an exemplary user device 110. As illustrated inFIG. 2, user device 110 may include a housing 205, a microphone 210, aspeaker 215, a keypad 220, and a display 225. In other implementations,user device 110 may include fewer, additional, and/or differentcomponents, and/or a different arrangement of components than thoseillustrated in FIG. 2 and described herein. For example, user device 110may not include microphone 210, speaker 215, and/or keypad 220.

Housing 205 may include a structure to contain components of user device110. For example, housing 205 may be formed from plastic, metal, or someother material. Housing 205 may support microphone 210, speakers 215,keypad 220, and display 225.

Microphone 210 may include an input device that converts a sound wave toa corresponding electrical signal. For example, the user may speak intomicrophone 210 during a telephone call or to execute a voice command.Speaker 215 may include an output device that converts an electricalsignal to a corresponding sound wave. For example, the user may listento music, listen to a calling party, or listen to other auditory signalsthrough speaker 215.

Keypad 220 may include an input device that provides input into userdevice 110. Keypad 220 may include a standard telephone keypad, a QWERTYkeyboard, and/or some other type or arrangement of keys. Keypad 220 mayalso include one or more special purpose keys. The user may utilizekeypad 220 as an input component to user device 110. For example, theuser may use keypad 220 to enter information, such as alphanumeric text,to access data, or to invoke a function or an operation.

Display 225 may include an output device that outputs visual content,and/or may include an input device that receives user input (e.g., atouch screen (also known as a touch display)). Display 225 may beimplemented according to a variety of display technologies, includingbut not limited to, a liquid crystal display (LCD), a plasma displaypanel (PDP), a field emission display (FED), a thin film transistor(TFT) display, or some other type of display technology. Additionally,display 225 may be implemented according to a variety of sensingtechnologies, including but not limited to, capacitive sensing, surfaceacoustic wave sensing, resistive sensing, optical sensing, pressuresensing, infrared sensing, gesture sensing, etc. Display 225 may beimplemented as a single-point input device (e.g., capable of sensing asingle touch or point of contact) or a multipoint input device (e.g.,capable of sensing multiple touches or points of contact that occur atsubstantially the same time).

Display 225 may also include an auto-rotating function thatautomatically orients content being displayed in correspondence to anorientation of display 225 and/or user device 110. For example, theauto-rotating function may automatically rotate content in a portraitmode or a landscape mode in correspondence to the orientation of display225 and/or user device 110.

Display 225 may display text, images, and/or video to the user. Display225 may also display a user interface (e.g., a graphical user interface(GUI)) of user device 110 or a user interface of some other device inwhich user device 110 controls, a user interface associated withapplications, or the like. The user may utilize his or her finger orsome other instrument (e.g., a stylus) to interact with display 225 (anduser device 110).

FIG. 3A is a diagram illustrating exemplary components of user device110. As illustrated, user device 110 may include a processing system305, memory/storage 310 including applications 315, a communicationinterface 320, an input 325, an output 330, and a smart card interface335. In other implementations, user device 110 may include fewer,additional, and/or different components, and/or a different arrangementof components than those illustrated in FIG. 3A and described herein.Additionally, in other implementations, some functions described asbeing performed by a particular component may be performed by adifferent component, or some combination thereof.

Processing system 305 may include one or more processors,microprocessors, data processors, co-processors, network processors,application specific integrated circuits (ASICs), controllers,programmable logic devices (PLDs), chipsets, field programmable gatearrays (FPGAs), and/or some other component that may interpret and/orexecute instructions and/or data. Processing system 305 may control theoverall operation, or a portion thereof, of user device 110, based on,for example, an operating system (not illustrated) and/or variousapplications (e.g., applications 315). Processing system 305 may accessinstructions from memory/storage 310, from other components of userdevice 110, and/or from a source external to user device 110 (e.g., anetwork or another device).

Memory/storage 310 may include memory and/or secondary storage. Forexample, memory/storage 310 may include a random access memory (RAM), adynamic random access memory (DRAM), a read only memory (ROM), aprogrammable read only memory (PROM), a flash memory, and/or some othertype of memory. Memory/storage 310 may include a hard disk (e.g., amagnetic disk, an optical disk, a magneto-optic disk, a solid statedisk, etc.) or some other type of computer-readable medium, along with acorresponding drive. The term “computer-readable medium” is intended tobe broadly interpreted to include a memory, a secondary storage, or thelike. A computer-readable medium may correspond to, for example, aphysical memory device or a logical memory device. A logical memorydevice may include memory space within a single physical memory deviceor spread across multiple physical memory devices.

Memory/storage 310 may store data, application(s), and/or instructionsrelated to the operation of user device 110. For example, memory/storage310 may include a variety of applications 315, such as, an e-mailapplication, a telephone application, a camera application, a voicerecognition application, a video application, a multi-media application,a music player application, a visual voicemail application, a contactsapplication, a data organizer application, a calendar application, aninstant messaging application, a texting application, a web browsingapplication, a location-based application (e.g., a GPS-basedapplication), a blogging application, and/or other types of applications(e.g., a word processing application, a spreadsheet application, etc.).

Communication interface 320 may include a component that permits userdevice 110 to communicate with other devices, networks (e.g., network125), and/or systems. For example, communication interface 320 mayinclude some type of wireless and/or wired interface.

Input 325 may include a component that permits the user and/or anotherdevice to input information into user device 110. For example, input 325may include a keypad (e.g., keypad 220), a button, a switch, a knob,fingerprint recognition logic, retinal scan logic, a web cam, voicerecognition logic, a touchpad, an input port, a microphone (e.g.,microphone 210), a display (e.g., display 225), and/or some other typeof input component. Output 330 may include a component that permits userdevice 110 to output information to the user and/or another device. Forexample, output 330 may include a display (e.g., display 225), lightemitting diodes (LEDs), an output port, a speaker (e.g., speaker 215),and/or some other type of output component.

Smart card interface 335 may provide an interface between user device110 and smart card 115. For example, UICC interface 335 may include acomponent to permit communication between user device 110 and smart card115 when smart card 115 is inserted in user device 110.

As described herein, user device 110 may perform certain operations inresponse to processing system 305 executing software instructionscontained in a computer-readable medium, such as memory/storage 310. Thesoftware instructions may be read into memory/storage 310 from anothercomputer-readable medium or from another device via communicationinterface 320. The software instructions contained in memory/storage 310may cause processing system 305 to perform processes described herein.Alternatively, hardwired circuitry may be used in place of or incombination with software instructions to implement processes describedherein. Thus, implementations described herein are not limited to anyspecific combination of hardware circuitry and software.

FIG. 3B is a diagram illustrating an exemplary functional componentassociated with user device 110. As illustrated in FIG. 3B, user device110 may include a smart card manager 340. Smart card manager 340 may beimplemented as a combination of hardware and software based on thecomponents illustrated and described with respect to FIG. 3A.Alternatively, smart card manager 340 may be implemented as hardwarebased on the components illustrated and described with respect to FIG.3A.

Smart card manager 340 may manage the sending of information to smartcard 115, the receiving of information from smart card 115, and/or theprocessing of information related to smart card 115, as well as otherprocesses associated with the utilization of smart card 115, asdescribed below. For example, smart card manager 340 may receive, fromsmart card 115, CDMA credentials and provide them to user device 110 sothat user device 110 may connect to and/or utilize network 125.Additionally, as previously described, when smart card 115 is removedfrom user device 110, smart card manager 340 may ensure that the CDMAcredentials are removed from user device 110.

As will be described in greater detail below, when smart card 115 isconnected with user device 110, a recognition process may occur. Forexample, in one implementation, when smart card 115 is placed in userdevice 110, smart card 115 may read an identifier (e.g., an IMEI)associated with user device 110. Smart card manager 340 may read anidentifier (e.g., an ICCID) associated with smart card 115. Smart card115 may compare the user device 110 identifier with a previously storeduser device identifier, if any. Similarly, smart card manager 340 maycompare the smart card 115 identifier with a previously stored smartcard identifier, if any. In the event that the smart card 115 identifiermatches a previously stored smart card identifier and the user device110 identifier matches a previously stored user device identifier, smartcard 115 may push the CDMA credentials to smart card manager 340. User105 may utilize user device 110 with network 125 without a need for userintervention and without the need to configure/program user device 110.

In other instances, however, when smart card manager 340 and smart card115 perform their respective comparisons, other outcomes may occur. Forexample, the user device 110 identifier may match a previously storeduser device identifier, but the smart card 115 identifier may not matcha previously stored smart card identifier. In another example, the userdevice 110 identifier may not match a previously stored user deviceidentifier and the smart card 115 identifier may not match a previouslystored smart card identifier. In either of these instances, in oneimplementation, smart card 115 may still push the CDMA credentials tosmart card manager 340. However, network devices, in network 125, mayneed to be provisioned to permit user 105, user device 110, and/or smartcard 115 to partake of services and/or resources in network 125, as willbe described in greater detail below.

FIG. 4A is a diagram illustrating exemplary components of smart card115. As illustrated, smart card 115 may include a processing system 405,a memory 410 including applications 415, and a device interface 420. Inother implementations, smart card 115 may include fewer, additional,and/or different components, and/or a different arrangement ofcomponents than those illustrated in FIG. 4A and described herein.

Processing system 405 may include one or more processors,microprocessors, data processors, co-processors, network processors,ASICs, controllers, PLDs, chipsets, FPGAs, and/or some other componentthat may interpret and/or execute instructions and/or data. Processingsystem 405 may control the overall operation, or a portion thereof, ofsmart card 115, based on, for example, an operating system (notillustrated) and/or various applications (e.g., applications 415).Processing system 405 may access instructions from memory 410, fromother components of smart card 115, and/or from a source external tosmart card 115 (e.g., user device 110).

Memory 410 may include a memory device. For example, memory 410 mayinclude a RAM, a DRAM, a ROM, a PROM, an electrically erasable PROM(EEPROM), a flash memory, and/or some other type of memory. Memory 410may store data, applications 415, and/or instructions related to theoperation of smart card 115.

Applications 415 may include applications associated with variousnetwork standards, such as GSM, CDMA, LTE, IMS, Universal MobileTelecommunication System (UMTS), etc.

Device interface 420 may include an interface between user device 110and smart card 115. For example, device interface 420 may includeelectronic circuitry to permit communication between user device 110 andsmart card 115 when smart card 115 is inserted in user device 110.Device interface 420 may serve as an input/output mechanism for smartcard 115.

FIG. 4B is a diagram illustrating exemplary functional components ofsmart card 115. The functional components may be implemented based onthe components illustrated and described with respect to FIG. 4A. Asillustrated, smart card 115 may include a Universal Subscriber IdentityModule (USIM) 425, an IP Multimedia Services Identity Module (ISIM) 430,and CDMA credentials module 435. In other implementations, smart card115 may include fewer, additional, and/or different functionalcomponents, and/or a different arrangement of functional components thanthose illustrated in FIG. 4B and described herein. Additionally, oralternatively, in other implementations, additional, fewer, and/ordifferent types of information may be stored by a particular componentthan the information described herein.

USIM 425 may correspond to an application (e.g., applications 415) thatstores subscriber information and/or authentication information whichmay be utilized when user device 110 connects to and/or utilizes network125. For example, USIM 425 may store GSM authentication information(e.g., an Authentication and Key Agreement (AKA) key), an IMSI, and/or aMSISDN. USIM 425 may also store a PLMN identifier.

ISIM 430 may correspond to an application (e.g., application 415) thatstores authentication information and/or other types of informationwhich may be utilized when user device 110 connects to and/or utilizesnetwork 125. For example, ISIM 430 may store an AKA key, and a SessionInitiation Protocol (SIP) Uniform Resource Indicator (URI) (e.g., a SIPURI of an Interrogating Call Session Control Function (I-CSCF)). ISIM430 may also store a telephone uniform resource identifier (URI) (e.g.,a global telephone number).

CDMA credentials module 435 may store CDMA credential information. CDMAcredentials module 435 may also store other types of information whichmay be utilized when user device 110 connects to and/or utilizes network125. For example, CDMA credentials module 435 may store a MDN, a MIN, aCDMA A12 NAI, a CDMA Network Access NAI, a PRL, and/or an IMEIassociated with user device 110. CDMA credentials module 435 may alsostore an FQDN.

Prior to activation of smart card 115, network 125 may provision certainnetwork devices so that network 125 may provide services and/orresources to user 105. FIG. 5 is a flowchart of an exemplary process 500for provisioning network devices in network 125. Process 500 may includeobtaining user information and device information (block 510). When auser (e.g., user 105) registers a user device (e.g., user device 110)with a service provider (e.g., a communications service provider), theservice provider may obtain certain information regarding user 105 anduser device 110. For example, the service provider may obtain theMSISDN, the MIN, the IMSI, and/or the IMEI associated with user 105and/or user device 110.

Key information may be obtained based on the user information and thedevice information (block 520). For example, one or more networkdevices, responsible for issuing keys (e.g., authentication keys), mayidentify and associate one or more keys with user 105 and/or user device110. The one or more keys might include one or more AKA keys,over-the-air (OTA) keys, and/or A-keys. Each of these keys may be usedfor later authentication of user 105 and/or user device 110.

Network devices may be provisioned based on the user information, thedevice information, and/or the key information (block 530). To permituser device 110 to partake of services and/or resources in network 125,certain network devices may be provisioned to recognize user 105 and/oruser device 110 and facilitate user 105 and/or user device 110 obtainingthese services and/or resources.

FIG. 6 is a diagram illustrating an exemplary messaging scheme forprovisioning network devices prior to activation of smart card 115. Thenetwork devices may be associated with network 125. As illustrated inFIG. 6, network 125 may include a billing system 605, a key system 610,a user device (UD) provisioning system 615, a home subscriber server(HSS) 620, a home location register (HLR) 625, an authentication,authorization, and accounting device (AAA) 630, and a UICC server 640.In other implementations, network 125 may include additional, fewer,and/or different network devices than those illustrated and describedwith respect to FIG. 6. For example, when network 125 includes a GSMnetwork and a CDMA network, the network devices may be different fromwhen network 125 includes a CDMA network and an LTE network.Additionally, or alternatively, in other implementations, theinformation exchanged between the network devices may be different.Additionally or alternatively, in other implementations, one or morefunctions described as being performed by a particular network devicemay be performed by a different network device.

Billing system 605 may correspond to a device that manages billing withrespect to users. Key system 610 may correspond to a device that stores,manages, and/or maintains keys (e.g., authentication keys). UDprovisioning system 615 may include a device that provisions networkdevices in network 125 so that network 125 may serve users 105, userdevices 110, and/or smart cards 115. HSS 620 may correspond to a devicethat manages user profile information. HSS 620 may include, or beassociated with, an HLR and/or an AAA. In one implementation, HSS 620may be associated with a GSM network, an LTE network, a 3^(rd)Generation Partnership Project (3GPP) network, or the like. HLR 625 maycorrespond to a device that manages location information associated withusers 105. In one implementation, HLR 625 may be associated with a CDMAnetwork, a 3GPP2 network, or the like. AAA 630 may correspond to adevice that provides authentication, authorization, and accountingservices. In one implementation, AAA 630 may be associated with a CDMAnetwork, a 3GPP2 network, or the like. UICC server 640 may include adevice that manages an activation of smart card 115.

As illustrated in FIG. 6, billing system 605, key system 610, UDprovisioning system 615, HSS 620, HLR 625, AAA 630, and UICC server 640may exchange various types of information to provision network 125 priorto smart card 115 being activated and recognized by network 125. Forexample, billing system 605 may initiate the process by sending amessage, containing information associated with user 105, user device110, and/or smart card 115, to UD provisioning system 615, as shown as(1) in FIG. 6. In one implementation, the information, associated withuser 105 and/or user device 110, may include the MSISDN, the MIN, theIMSI, and/or the IMEI.

UD provisioning system 615 may receive the message from billing system605, and coordinate the provisioning of other network devices in network125. For example, UD provisioning system 615 may send a message to keysystem 610, as shown as (2) in FIG. 6. In one implementation, themessage, from UD provisioning system 615, may include the IMSI and/orthe IMEI. In response to the message, key system 610 may identify one ormore keys, such as one or more AKA keys, over-the-air (OTA) keys, and/orA-keys, and associate the one or more keys with user 105 and/or userdevice 110. Each of these keys may be used for later authentication ofuser 105 and/or user device 110. Key system 610 may send a responsemessage to UD provisioning system 615 with the one or more AKA keys, OTAkeys, and/or A-keys, as shown as (3) in FIG. 6.

UD provisioning system 615 may, in turn, provision HSS 620, HLR 625, AAA630, and UICC server 640. For example, UD provisioning system 615 maysend a message to HSS 620, as shown as (4) in FIG. 6. In oneimplementation, this message, to HSS 620, may include the MSISDN, theIMSI, and/or USIM, ISM, and/or GSM AKA keys. HSS 620 may record theinformation contained within the message and/or perform one or moreprocesses necessary to associate the information with user 105 and/oruser device 110 to facilitate utilization of network 125.

UD provisioning system 615 may also send a message to HLR 625, as shownas (5) in FIG. 6. In one implementation, this message, to HLR 625, mayinclude the MDN, the MIN, the IMEI, and the A-key. HLR 620 may recordthe information contained within the message and/or perform one or moreprocesses necessary to associate the information with user 105 and/oruser device 110 to facilitate utilization of network 125.

UD provisioning system 615 may also send a message to AAA 630, as shownas (6) in FIG. 6. In one implementation, this message, to AAA 630, mayinclude the MDN, the MIN, the CDMA A12 NAI, and/or the CDMA networkaccess NAI. AAA 630 may record the information contained within themessage and/or perform one or more processes necessary to associate theinformation with user 105 and/or user device 110 to facilitateutilization of network 125.

UD provisioning system 615 may also send a message to UICC server 640,as shown as (7) in FIG. 6. In one implementation, the message, to UICCserver 640, may include the MDN, the MIN, the IMEI, the A-key, the PLMNidentifier, and/or the PRL. UICC server 640 may record the informationcontained within the message and/or perform one or more processesnecessary to associate the information with user 105 and/or user device110 to facilitate utilization of network 125.

Based on the foregoing, network devices, in network 125, may beprovisioned so that network 125 may provide services and/or resources touser 105 and/or user device 110. Once network devices, in network 125,have been provisioned, smart card 115, of user device 110, may beactivated so that user device 110 may partake of services and/orresources in network 125.

FIG. 7 is a flow chart of a process 700 for activating smart card 115.Process 700 may be performed by one or more network devices, in network125, in communication with user device 110 and/or smart card 115.Examples of these network devices are described below in connection withFIGS. 8-10.

Process 700 may include receiving a request to attach to network 125(block 710). For example, user device 110 may send an attachment requestto a first network device. This may occur when user 105 powers on, orotherwise activates, user device 110. In one implementation, user device110 may send an attachment request message that might includeinformation associated with user 105 and/or user device 110, such as theIMSI. The first network device may process the attachment request, and,if user 105 and/or user device 110 is recognized (e.g., is a registereduser and/or user device), permit user device to attach to network 125.

A data connection may be established (block 720). For example, userdevice 110 may send a request to establish a data connection with asecond network device. After processing the request, the second networkdevice may permit a data connection, such as an IP connection, to beestablished with user device 110.

A request to activate smart card 115 may be received (block 730). Forexample, smart card 115 may send an activation request to a thirdnetwork device. The activation request may include informationassociated with user 105 and/or user device 110, such as the IMSI and/orthe IMEI. In one implementation, the IMSI and the IMEI may beincorporated with a FQDN (e.g., IMSI@vz3G.com and IMEI@vz4g.com).

It may be determined whether user device 110 is registered (block 740).In one implementation, the third network device may determine whetheruser device 110 is registered by comparing the IMEI, received from smartcard 115, to a set of stored IMEIs, corresponding to a set of userdevices with which the third network device has previously communicated.The third network device may conclude that a user device 110 isregistered if the received IMEI matches an IMEI in the stored set ofIMEIs.

If user device 110 is registered (block 740—YES), then an activationresponse may be sent to activate smart card 115 (block 750). In oneimplementation, the activation response may include information thatuser device 110 may use to partake of services and/or resources innetwork 125. The information, in the activation response, may include,for example, the MSISDN, the MIN, the CDMA A12 NAI, the PRL, the PLMNidentifier, and/or the CDMA network access NAI. Smart card 115 may storethis information in its memory (e.g., memory 410 (FIG. 4A)) and/or pushsome or all of the information (e.g., the CDMA credentials) to userdevice 110. Accordingly, smart card 115 may be activated. Thereafter,user device 110 may use information in/from smart card 115 to partake inservices and/or resources on network 125.

If user device 110 is not registered (block 740—NO), then user device110 may be registered (block 760). For example, the third network devicemay cause one or more other network devices to store informationassociated with user device 110, authenticate user 105 and/or userdevice 110, and/or perform one or more other functions to register userdevice 110.

Once user device 110 is registered, then an activation response may besent to activate smart card 115 (block 770). In one implementation, theactivation response may include information that user device 110 may useto partake of services and/or resources in network 125. The information,in the activation response, may include, for example, the MSISDN, theMIN, the CDMA A12 NAI, the PRL, the PLMN identifier, and/or the CDMAnetwork access NAI. Smart card 115 may store this information in itsmemory (e.g., memory 410 (FIG. 4A)) and/or push some or all of theinformation (e.g., the CDMA credentials) to user device 110.Accordingly, smart card 115 may be activated. Thereafter, user device110 may use information in/from smart card 115 to partake in servicesand/or resources on network 125.

FIG. 8 is a diagram illustrating an exemplary messaging scheme forassociated with an activation procedure for smart card 115 when LTEcoverage is provided in network 125. In this example, network 125 mayinclude network devices previously illustrated and described withrespect to FIG. 6. Additionally, network 125 may include a packetgateway (PGW) 810. PGW 810 may serve as a gateway to and from packetnetworks (e.g., the Internet or other IP-based networks) and istypically associated with an LTE network.

As illustrated in FIG. 8, user device 110 may send an attachment requestto HSS 620, as shown as (1) in FIG. 8. In one implementation, theattachment request may include an IMSI associated with user 105. HSS 620may determine whether to accept the attachment request based on theIMSI. User device 110 may establish a data connection with PGW 810, asshown as (2) in FIG. 8. For example, user device 110 may send a request,to PGW 810, to establish an IP connection, and PGW 810 may process therequest. Although not shown in FIG. 8, the data connection may be usedfor other communication to/from user device 110.

Smart card 115 may transmit an activation request to UICC server 640, asshown as (3) in FIG. 8. In one implementation, the activation requestmay include the IMEI and the IMSI associated with user device 110 anduser 105, respectively. Additionally, in one implementation, the IMEIand the IMSI may be incorporated with a FQDN (e.g., IMEI@vz4g.com andIMSI@vz3G.com).

In one implementation, UICC server 640 may determine whether user device110 is registered. For example, UICC server 640 may compare the receivedIMEI, included in the activation request, with IMEIs that UICC server640 may store in accordance with a previous provisioning, as describedwith regard to FIG. 6. As illustrated, if the received IMEI matches analready provisioned IMEI (IMEI_P) (i.e., IMEI=IMEI_P), UICC server 640may send an activation response to smart card 115, as shown as (4) inFIG. 8. In one implementation, the activation response may include theMSISDN, the MIN, the CDMA A12 NAI, the PRL, the PLMN identifier, and/orthe CDMA network access NAI. Smart card 115 may store this informationin its memory (e.g., memory 410 (FIG. 4A) and/or push some or all of theinformation (e.g., the CDMA credentials) to user device 110.Accordingly, smart card 115 may be activated. Thereafter, user device110, containing smart card 115, may partake in services and/or resourceson network 125.

On the other hand, if the received IMEI does not match an alreadyprovisioned IMEI (i.e., IMEI≠IMEI_P), then to be able to activate smartcard 115, UICC server 640 may register user device 110 with othernetwork devices. For example, UICC server 640 may send a request for UDprovisioning system 615 to register user device 110, as shown as (5) inFIG. 8. In one implementation, the request may include the IMEIassociated with user device 110.

UD provisioning system 615 may send a message to billing system 605and/or key system 610 instructing these devices to register user device110, as shown as (6) in FIG. 8. In response to the message, from UDprovisioning system 615, billing system 605 may perform one morefunctions to register user device 110, and key system 610 may identifythe A-key associated with user device 110. Key system 610 may send aresponse message to UD provisioning system 615, as shown as (7) in FIG.8. In one implementation, the response message may include an A-keyidentified by key system 610. Billing system 605 may also send aresponse message to UD provisioning system 615, although this aspect isnot shown in FIG. 8.

UD provisioning system 615 may receive the A-key and send a message toHLR 625 and/or AAA 630 instructing these devices to register user device110, as shown as (8) in FIG. 8. In one implementation, the message, toHLR 625 and/or AAA 630, may include the IMEI and the A-key. HLR 625 mayperform one more functions to register user device 110, and AAA 630 mayperform an authentication operation based on the IMEI and the A-key. AAA630 may return a response message to UD provisioning system 615, asshown as (9) in FIG. 8. Upon successful authentication by AAA 630, theresponse message, to UD provisioning system 615, may include anindication of successful authentication (e.g., OK). Upon unsuccessfulauthentication by AAA 630, the response message, to UD provisioningsystem 615, may include an indication of an unsuccessful authentication(e.g., FAIL). HLR 625 may also send a response message to UDprovisioning system 615, although this aspect is not shown in FIG. 8.

UD provisioning system 615 may receive the response message from AAA 630and return a response message to UICC server 640, as shown as (10) inFIG. 8. If the registration process was successful (e.g., an A-key isreceived from key system 610, an OK indication in received from AAA 630,etc.), the response message, to UICC server 640, may include anindication of successful registration (e.g., OK). If the registrationprocess was unsuccessful, the response message, to UICC server 640, mayinclude an indication of an unsuccessful registration (e.g., FAIL).

UICC server 640 may send an activation response to smart card 115, asshown as (11) in FIG. 8. If the registration was unsuccessful, theactivation response may indicate a failure. If the registration wassuccessful, the activation response may include the MSISDN, the MIN, theCDMA A12 NAI, the PRL, the PLMN identifier, and/or the CDMA networkaccess NAI. Smart card 115 may store this information in its memory(e.g., memory 410 (FIG. 4A) and/or push some or all of the information(e.g., the CDMA credentials) to user device 110. Accordingly, smart card115 may be activated. Thereafter, user device 110, containing smart card115, may partake in services and/or resources on network 125.

FIG. 9 is a diagram illustrating an exemplary messaging schemeassociated with an activation procedure for smart card 115 when eHRPDcoverage is provided in network 125. In this example, network 125 mayinclude network devices previously illustrated and described withrespect to FIGS. 6 and 8. In FIG. 9, however, HSS 620 may be replacedwith one or more 3GPP devices, such as HSS 910 and/or AAA 920. HSS 910may correspond to a device that manages user profile information. AAA920 may correspond to a device that provides authentication,authorization, and accounting services.

The activation procedure of FIG. 9 may be similar to the activationprocedure described above with regard to FIG. 8. In the activationprocedure of FIG. 9, however, when user device 110 sends an attachmentrequest, as shown as (1) in FIG. 9, user device 110 may send theattachment request to HSS 910 and/or AAA 920. In one implementation, theattachment request may include the IMSI associated with user 105 and aNAI. HSS 910 may perform a function relating to the attachment of userdevice 110 to network 125. AAA 920 may perform an authenticationfunction relating to user device 110. Based on a result of the functionperformed by HSS 910 and/or AAA 920, HSS 910 and/or AAA 920 maydetermine whether to accept the attachment request.

FIG. 10 is a diagram illustrating an exemplary messaging schemeassociated with an activation procedure for smart card 115 when 1X RadioTransmission Technology (RTT) (1XRTT) and HRPD coverage is provided innetwork 125. In this example, network 125 may include network devicespreviously illustrated and described with respect to FIGS. 6 and 8.Additionally, network 125 may include a home agent (HA) 1010 and an AAA1020. HA 1010 may correspond to a device that routes data to user device110 when user device 110 is attached to a network other than network125. For example, HA 1010 may correspond to an anchor point. AAA 1020may correspond to a device that provides authentication, authorization,and accounting services.

The activation procedure of FIG. 10 may be similar to the activationprocedure described above with regard to FIG. 8. In the activationprocedure of FIG. 10, however, when user device 110 sends an attachmentrequest, as shown as (1) in FIG. 10, user device 110 may send theattachment request to AAA 1020. In one implementation, AAA 1020 mayperform an attachment procedure using authentication bypass. AAA 1020may determine whether to accept the attachment request based on a resultof the attachment procedure.

User device 110 may establish a data connection with HA 1010, as shownas (2) in FIG. 10. For example, user device 110 may send a request, toHA 1010, to establish an IP connection, and HA 1010 may process therequest. User device 110 may also establish a connection with UICCserver 540, as shown as (3) in FIG. 10. In one implementation, thisconnection may be hot-lined.

The rest of the activation procedure of FIG. 10 may be similar to theactivation procedure described above with regard to FIG. 8.

FIG. 11 is a flowchart of an exemplary process 1100 that may occur whena smart card is moved from one user device to another user device. Forexample, with reference to FIGS. 1A and 1B, assume that user 105 removessmart card 115 from user device 110-1 and inserts smart card 115 intouser device 110-2. Process 1100 may be performed by user device 110-2,smart card 115, or a combination of user device 110-2 and smart card115.

Process 1100 may include reading a user device identifier and comparingthe user device identifier to a stored user device identifier (block1110). For example, once inserted into user device 110-2, smart card 115may read (or otherwise obtain) a user device identifier (e.g., the IMEI)associated with user device 110-2. Smart card 115 may obtain the userdevice identifier by, for example, reading the user device identifierfrom a particular memory location within user device 110-2 or requestinguser device 110-2 to provide the user device identifier. Smart card 115may also determine a user device identifier (IMEI_S) of the last userdevice 110 with which smart card 115 was associated. For example, asdescribed above, CDMA credentials module 435 (FIG. 4B) may store a userdevice identifier of a user device 110 with which smart card 115 isassociated. Smart card 115 may compare the user device identifier (e.g.,the IMEI) with the stored user device identifier (e.g., IMEI_S) todetermine whether they match (e.g., whether IMEI=IMEI_S). In analternative implementation, rather than smart card 115 reading the userdevice identifier and performing the comparison, one or both of theseoperations may be performed by user device 110-2.

A smart card identifier may be read and compared to a stored smart cardidentifier (block 1120). For example, once inserted into user device110-2, user device 110-2 may read (or otherwise obtain) a smart cardidentifier (e.g., the ICCID) associated with smart card 115. User device110-2 may obtain the smart card identifier by, for example, reading thesmart card identifier from a particular memory location within smartcard 115 or requesting smart card 115 to provide the smart cardidentifier. User device 110-2 may also determine a smart card identifier(ICCID_S) of the last smart card 115 inserted into user device 110-2.For example, user device 110-2 may store a smart card identifierassociated with a smart card 115 that has been inserted into user device110-2. User device 110-2 may compare the smart card identifier (e.g.,the ICCID) with the stored smart card identifier (e.g., ICCID_S) todetermine whether they match (e.g., whether ICCID=ICCID_S). In analternative implementation, rather than user device 110-2 reading thesmart card identifier and performing the comparison, one or both ofthese operations may be performed by smart card 115.

If the smart card identifiers match (i.e., ICCID=ICCID_S), theninformation from smart card 115 may be pushed to user device 110-2(block 1130). For example, if the smart card identifiers match, thenthis may imply that the user device identifiers also match. This may bethe case where smart card 115 has not been used with, or tied to, anyother user device (other than user device 110-2) (i.e., smart card 115was last used with user device 110-2), and user device 110-2 has notbeen used with any other smart card (other than smart card 115) (i.e.,the last smart card used by user device 110-2 was smart card 115).

Smart card 115 may push information, such as the CDMA credentials, touser device 110-2. User device 110-2 may then use the information toobtain services and/or resources on network 125. In this case, userdevice 110-2 may access network 125 without the need toconfigure/program user device 110-2 and without the need for any userintervention.

If the smart card identifiers do not match (i.e., ICCID≠ICCID_S) and theuser device identifiers match (i.e., IMEI=IMEI_S), then information fromsmart card 115 may be pushed to user device 110-2 (block 1140). This maybe the case where smart card 115 has not been used with, or tied to, anyother user device (other than user device 110-2) (i.e., the last userdevice with which smart card 115 was used was user device 110-2), anduser device 110-2 has been used with another smart card (other thansmart card 115) (i.e., the last smart card used by user device 110-2 wasnot smart card 115). In this case, smart card 115 may push information,such as the CDMA credentials, to user device 110-2.

A process to configure/program user device 110-2 may be initiated (block1150). For example, smart card 115 may send a request to a networkdevice to obtain configuration/programming information toconfigure/program user device 110-2.

FIG. 12 is a diagram illustrating an exemplary messaging scheme forobtaining configuration/programming information to configure/programuser device 110-2. In this example, network 125 may include networkdevices previously illustrated and described with respect to FIG. 6.Additionally, network 125 may include a configuration server 1110.Configuration server 1110 may include a device that may communicate withuser device 110-2 and/or smart card 115 to provideconfiguration/programming information to configure/program user device110-2.

As illustrated in FIG. 12, smart card 115 may send a configurationrequest to UICC server 640, as shown as (1) in FIG. 12. In oneimplementation, the configuration request may include the IMEIassociated with user device 110-2. UICC server 640 may receive theconfiguration request, process the configuration request, and issue acorresponding configuration request to UD provisioning system 615, asshown as (2) in FIG. 12. In one implementation, the configurationrequest, from UICC server 640, may include the IMEI associated with userdevice 110-2. UD provisioning system 615 may receive the configurationrequest, process the configuration request, and issue a correspondingconfiguration request to billing system 605 and/or key system 610, asshown as (3) in FIG. 12. In one implementation, the configurationrequest, from UD provisioning system 615, may include the IMEIassociated with user device 110-2.

Billing system 605 and/or key system 610 may receive the configurationrequest and identify configuration information associated with the IMEIcontained in the configuration request. In one implementation, theconfiguration information may include configuration/programminginformation used to configure/program user device 110-2. Theconfiguration information may take the form of a data file, anexecutable application, or the like. Billing system 605 and/or keysystem 610 may send the configuration information to UD provisioningsystem 615, as shown as (4) in FIG. 12.

UD provisioning system 615 may receive the configuration information andprovide the configuration information to configuration server 1110, asshown as (5) in FIG. 12. Configuration server 1110 may configure/programuser device 110-2 using the configuration information, as shown as (6)in FIG. 12. For example, a data connection (e.g., an IP connection) maybe established between user device 110-2 and configuration server 1110.Configuration server 1110 may configure/program user device 110-2, overthe data connection, so that user device 110-2 can partake of servicesand/or resources on network 125.

As a result, user device 110-2 may then obtain services and/or resourceson network 125. In this case, user device 110-2 may access network 125without the need for any user intervention.

Returning to FIG. 11, if the smart card identifiers do not match (i.e.,ICCID≠ICCID_S) and the user device identifiers also do not match (i.e.,IMEI≠IMEI_S), then information from smart card 115 may be pushed to userdevice 110-2 (block 1160). This may be the case where smart card 115 hasbeen used with, or tied to, another user device (other than user device110-2) (i.e., the last user device with which smart card 115 was usedwas not user device 110-2), and user device 110-2 has been used withanother smart card (other than smart card 115) (i.e., the last smartcard used by user device 110-2 was not smart card 115). In this case,smart card 115 may push information, such as the CDMA credentials, touser device 110-2.

One or more network devices may be updated with the user deviceidentifier associated with user device 110-2 (block 1170). For example,smart card 115 may initiate an update process to cause one or morenetwork devices to recognize user device 110-2.

FIG. 13 is a diagram illustrating an exemplary messaging scheme forupdating one or more network devices with information regarding userdevice 110-2. In this example, network 125 may include network devicespreviously illustrated and described with respect to FIGS. 6, 8, and 9.

As illustrated in FIG. 13, smart card 115 may send an update request toUICC server 640, as shown as (1) in FIG. 13. In one implementation, theupdate request may include the IMEI and the IMSI associated with userdevice 110-2 and user 105, respectively. Additionally, in oneimplementation, the IMEI and the IMSI may be incorporated with a FQDN(e.g., IMEI@vz4g.com and IMSI@vz3G.com).

UICC server 640 may recognize the request as an update request andinitiate a process for updating one or more other network devices, suchas HLR 625. UICC server 640 may send a request for UD provisioningsystem 615 to update the one or more other network devices, as shown as(2) in FIG. 13. In one implementation, the request may include the IMEIassociated with user device 110-2.

UD provisioning system 615 may send a message to billing system 605and/or key system 610 instructing these devices to provide informationassociated with user device 110-2, as shown as (3) in FIG. 13. Inresponse to the message, from UD provisioning system 615, billing system605 may obtain information associated with user device 110-2, and/or keysystem 610 may identify the A-key associated with user device 110-2. Keysystem 610 may send a response message to UD provisioning system 615, asshown as (4) in FIG. 13. In one implementation, the response message mayinclude an A-key identified by key system 610. Billing system 605 mayalso send a response message to UD provisioning system 615, althoughthis aspect is not shown in FIG. 13.

UD provisioning system 615 may receive the A-key and send a message toHLR 625 and/or AAA 630 instructing these devices to update informationregarding user device 110-2, as shown as (5) in FIG. 13. In oneimplementation, the message, to HLR 625 and/or AAA 630, may include theIMEI and the A-key. HLR 625 may perform one more functions to update itsrecords with information regarding user device 110-2, and/or AAA 630 mayperform an authentication operation based on the IMEI and the A-key. AAA630 may return a response message to UD provisioning system 615,although this aspect is not shown in FIG. 13. HLR 625 may also return aresponse message to UD provisioning system 615, as shown as (6) in FIG.13. In one implementation, the response message, to UD provisioningsystem 615, may include an indication of a successful update operation(e.g., OK). Alternatively, the response message, to UD provisioningsystem 615, may include an indication of an unsuccessful updateoperation (e.g., FAIL).

UD provisioning system 615 may receive the response message from HLR 625and return a response message to UICC server 640, as shown as (7) inFIG. 13. If the update process was successful (e.g., an A-key isreceived from key system 610, an OK indication in received from HLR 625,etc.), the response message, to UICC server 640, may include anindication of successful update (e.g., OK). If the update process wasunsuccessful, the response message, to UICC server 640, may include anindication of an unsuccessful update (e.g., FAIL). UICC server 640 maysend a response to smart card 115, as shown as (8) in FIG. 13. If theupdate was unsuccessful, the response may include an indication of anunsuccessful update (e.g., FAIL). If the update was successful, theresponse may include an indication of successful update (e.g., OK).

Returning to FIG. 11, a process to configure/program user device 110-2may be initiated (block 1180). For example, smart card 115 may send arequest to a network device to obtain configuration/programminginformation to configure/program user device 110-2. In oneimplementation, the procedure performed to obtainconfiguration/programming information to configure/program user device110-2 may be similar to the procedure described with regard to FIG. 12.As a result, user device 110-2 may then obtain services and/or resourceson network 125. In this case, user device 110-2 may access network 125without the need for any user intervention.

Implementations, described herein, may permit a smart card to be movedfrom a first user device to a second user device, and the second userdevice to then be used to obtain network services and/or resourceswithout user intervention.

The foregoing description provides illustration and description, but isnot intended to be exhaustive or to limit the invention to the preciseform disclosed. Modifications and variations are possible in light ofthe above teachings or may be acquired from practice of the invention.

For example, while series of blocks have been described with regard toFIGS. 5, 7, and 11, the order of the blocks may be changed in otherimplementations. Also, non-dependent blocks may be performed inparallel.

Also, certain functions have been described as being performed by smartcard 115 and certain other functions have been described as beingperformed by user device 110. In other implementations, one or more ofthe functions, described as being performed by smart card 115, may beperformed by user device 110; and/or one or more of the functions,described as being performed by user device 110, may be performed bysmart card 115.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the invention. In fact, many ofthese features may be combined in ways not specifically recited in theclaims and/or disclosed in the specification. Although each dependentclaim listed below may directly depend on only one other claim, thedisclosure of the invention includes each dependent claim in combinationwith every other claim in the claim set.

No element, act, or instruction used in the present application shouldbe construed as critical or essential to the invention unless explicitlydescribed as such. Also, as used herein, the article “a” is intended toinclude one or more items. Where only one item is intended, the term“one” or similar language is used. Further, the phrase “based on” isintended to mean “based, at least in part, on” unless explicitly statedotherwise.

The invention claimed is:
 1. A system, comprising: one or more devicesto: receive a first request to activate a smart card associated with auser device, determine, based on the first request, whether the userdevice is registered to communicate on a network, send, when the userdevice is not registered, a second request to register the user device,the user device being registered to communicate on the network based onthe second request, receive a notification based on the user devicebeing registered, and send, to the smart card, an activation response toactivate the smart card based on either: determining that the userdevice is registered, or receiving the notification, the activationresponse including information that, when accessed from the smart card,enables the user device to communicate with the network, the one or moredevices including a provisioning system, and the one or more devices,when sending the activation response, being further to: send, from theprovisioning system and to a key system, a first message that includesan identifier associated with the user device, receive, by theprovisioning system and from the key system, a second message thatincludes a key associated with the user device, the key systemidentifying the key based on the identifier associated with the userdevice, send, from the provisioning system and to an authentication,authorization, and accounting (AAA) device, a third message thatincludes the identifier associated with the user device and the key,receive, by the provisioning system and from the AAA device, resultsassociated with authenticating the user device based on at least one ofthe identifier associated with the user device or the key, anddetermine, by the provisioning system, to send the activation responsebased on the result.
 2. The system of claim 1, where the information,included in the activation response, includes at least one of: a mobilestation international subscriber directory number (MSISDN), a mobiledirectory number (MDN), a mobile identification number (MIN), apreferred roaming list (PRL), a public land mobile network (PLMN)identifier, a code division multiple access (CDMA) A12 network accessidentifier (NAI), or a CDMA NAI.
 3. The system of claim 1, where thefirst request includes the identifier associated with the user device,and where, when determining whether the user device is registered, theone or more devices are further to: compare the identifier, associatedwith the user device, to a set of identifiers associated with other userdevices, the other user devices being registered prior to receiving thefirst request, and determine that the user device is registered when theidentifier, associated with the user device, is included in the set ofidentifiers.
 4. The system of claim 1, where the one or more devices arefurther to at least one of: store information associated with the userdevice, or authenticate one or more of the user device or a user of theuser device based on the stored information.
 5. The system of claim 1,where the one or more devices further include: a home subscriber server,and a packet gateway, where the home subscriber server is to: receive anattachment request from the user device, the attachment requestincluding an identifier associated with a user of the user device andinformation associated with the smart card, and determine whether toaccept the attachment request based on the identifier associated withthe user and the information associated with the smart card, and wherethe packet gateway is to: receive a connection request from the userdevice based on the home subscriber server determining to accept theattachment request, and establish a data connection with the user devicebased on data included in the connection request.
 6. The system of claim1, where the one or more devices further include: a packet gateway,where the AAA device is to: receive an attachment request from the userdevice, the attachment request including information associated with thesmart card, perform an authentication function regarding the user devicebased on the information included in the attachment request, anddetermine whether to accept the attachment request based on a result ofthe authentication function, and where the packet gateway is to: receivea connection request from the user device based on the AAA devicedetermining to accept the attachment request, and establish a dataconnection with the user device based on information in the connectionrequest.
 7. The system of claim 1, where the one or more devices furtherinclude: a home agent, where the AAA device is to: receive an attachmentrequest from the user device, the attachment request includinginformation associated with the smart card, perform an authenticationfunction regarding the user device based on the information included inthe attachment request, and determine whether to accept the attachmentrequest based on a result of the authentication function, and where thehome agent is to: receive a connection request from the user device, andestablish a data connection with the user device based on the connectionrequest.
 8. A method, comprising: receiving, by one or more devices, arequest to activate a smart card associated with a user device, thesmart card being different from the user device; determining, by the oneor more devices and based on the request, that the user device isunregistered; registering, by the one or more devices and based on therequest, the user device, the registering of the user device including:causing the smart card to update credentials of the user device, andreceiving, from the smart card, information associated with the updatedcredentials of the user device; and sending, by the one or more devicesand to the smart card, an activation response to activate the smart cardafter the user device is registered, the activation response includinginformation, based on the updated credentials, to enable the user deviceto communicate with a particular network, the activation responsecausing the smart card to program the user device to access theparticular network using the information included in the activationresponse, and the one or more devices including a provisioning system,and sending the activation response further including: sending, from theprovisioning system and to a key system, a first message that includesan identifier associated with the user device, receiving, by theprovisioning system and from the key system, a second message thatincludes a key associated with the user device, the key systemidentifying the key based on the identifier associated with the userdevice, sending, from the provisioning system and to an authentication,authorization, and accounting (AAA) device, a third message thatincludes the identifier associated with the user device and the key,receiving, by the provisioning system and from the AAA device, resultsassociated with authenticating the user device based on at least one ofthe identifier associated with the user device or the key, anddetermining, by the provisioning system, to send the activation responsebased on the result.
 9. The method of claim 8, where the information,included in the activation response, includes at least one of: a mobilestation international subscriber directory number (MSISDN), a mobiledirectory number (MDN), a mobile identification number (MIN), apreferred roaming list (PRL), a public land mobile network (PLMN)identifier, a code division multiple access (CDMA) A12 network accessidentifier (NAI), or a CDMA NAI.
 10. The method of claim 8, where therequest includes the identifier associated with the user device, andwhere determining whether the user device is registered includes:comparing the identifier, associated with the user device, to a set ofidentifiers associated with other user devices, and determining that theuser device is registered when the identifier, associated with the userdevice, corresponds to an identifier in the set of identifiersassociated with the other user devices.
 11. The method of claim 8, whereregistering the user device further includes: storing informationassociated with the user device, and authenticating, based on the storedinformation, the user device or a user of the user device.
 12. Themethod of claim 8, further comprising: receiving an attachment requestfrom the user device, the attachment request including an identifierassociated with a user of the user device and information associatedwith the smart card; determining whether to accept the attachmentrequest based on the identifier associated with the user and theinformation associated with the smart card; receiving a connectionrequest from the user device based on determining to accept theattachment request; and establishing a data connection with the userdevice based on data included in the connection request.
 13. The methodof claim 8, further comprising: receiving an attachment request from theuser device, the attachment request including information associatedwith the smart card; performing an authentication function regarding theuser device based on the information included in the attachment request;determining whether to accept the attachment request based on a resultof the authentication function; receiving a connection request from theuser device; and establishing a data connection with the user devicebased on information in the connection request and based on determiningto accept the attachment request.
 14. A non-transitory computer-readablemedium to store instructions, the instructions comprising: one or moreinstructions that, when executed by one or more devices, cause the oneor more devices to: receive a request to activate a smart cardassociated with a user device, the smart card being different from theuser device; determine, based on the request, that the user device isunregistered; send, to the smart card and based on determining the userdevice is unregistered, an activation response, the activation responsecausing the smart card to update credentials of the user device, the oneor more devices including a provisioning system, and one or moreinstructions, to send the activation response, further including: atleast one instruction to: send, from the provisioning system and to akey system, a first message that includes an identifier associated withthe user device, receive, by the provisioning system and from the keysystem, a second message that includes a key associated with the userdevice,  the key system identifying the key based on the identifierassociated with the user device, send, from the provisioning system andto an authentication, authorization, and accounting (AAA) device, athird message that includes the identifier associated with the userdevice and the key, receive, by the provisioning system and from the AAAdevice, results associated with authenticating the user device based onat least one of the identifier associated with the user device or thekey, and determine, by the provisioning system, to send the activationresponse based on the result; receive, from the smart card, informationassociated with the updated credentials of the user device; and causethe smart card to program the user device to access a particular networkbased on the updated credentials.
 15. The non-transitorycomputer-readable medium of claim 14, where the instructions furthercomprise: one or more instructions that, when executed by the one ormore devices, cause the one or more devices to: receive an attachmentrequest from the user device, the attachment request including anidentifier associated with a user of the user device and informationassociated with the smart card; determine whether to accept theattachment request based on the identifier associated with the user andthe information associated with the smart card; receive a connectionrequest from the user device; and establish a data connection with theuser device based on data included in the connection request and basedon determining to accept the attachment request.
 16. The non-transitorycomputer-readable medium of claim 14, where the instructions furthercomprise: one or more instructions that, when executed by the one ormore devices, cause the one or more devices to: receive an attachmentrequest from the user device, the attachment request includinginformation associated with the smart card; perform an authenticationfunction regarding the user device based on the information included inthe attachment request; determine whether to accept the attachmentrequest based on a result of the authentication function; receive aconnection request from the user device; and establish a data connectionwith the user device based on information in the connection request andbased on determining to accept the attachment request.
 17. Thenon-transitory computer-readable medium of claim 14, where theinstructions further comprise: one or more instructions that, whenexecuted by the one or more devices, cause the one or more devices to:authenticate, based on at least one of the identifier associated withthe user device or the key, the user device to generate anauthentication result; and cause the smart card to program the userdevice further based on the authentication result.